1. Field of the Invention
The present invention relates to a data receiving apparatus, data receiving method, and program storage medium for receiving data transmitted over a network using a predetermined protocol.
2. Related Art
TCP/IP is one of major protocols used in Internet communication. Conventional TCP/IP is realized mainly through software processing and implemented by a CPU in a personal computer or an embedded device, for example. In such a case, data from a network is received using a Network Interface Card (NIC), and received frames are once written in a stack buffer of memory by the NIC itself or the CPU and subsequently subjected to protocol processing by protocol stack software of the CPU. The CPU is typically performing application processing in addition to protocol processing, and the data is copied to an application buffer specified by an application after protocol processing is performed. The stored data is read out by the application or the like. This flow of data is illustrated in FIG. 31.
In this scheme, however, received data is once buffered while it moves from the NIC to the application buffer, meaning the data makes two roundtrips across the memory in total. To address this, U.S. Patent Publication No. 2004-0078462 discloses a scheme for directly writing data in an application buffer from a NIC by performing part of protocol processing in the NIC. Data flow in this scheme is as shown in FIG. 32. In this arrangement, the data flow makes only one roundtrip across the memory and it is thus possible to avoid overhead in terms of performance and power consumption associated with data copy.
However, such problems as follows would be encountered when the technique of U.S. Patent Publication No. 2004-0078462 is used as it is:
(1) Application Problem
A typical application program is often run using a socket API. An approach often used in such a case is to wait for reception of data in a select( ) function, for example, and call a recv( ) function upon verification of reception. An application specifies an address in an application buffer and a protocol processing unit writes data at the specified address, but in this approach the application notifies the address through a recv( ) function. Accordingly, when such an application is to be handled, data has to be once buffered on the way because it is required to receive data without an application buffer specified, that is to say, with no application buffer being present.
(2) Performance Problem
Even if reception is awaited in “recv( )”, data cannot be received because there is no application buffer until a recv( ) call returns after data reception and the next recv( ) call is called, making data reception intermittent as shown in FIG. 33 and degrading performance.
(3) Window Size Notification Problem
The U.S. Patent Publication No. 2004-0078462 describes a scheme for informing the other party of the size of a receive window as the size of the application buffer, but actually a larger size has to be informed as described below.
When a window scaling option is used, a window size for notification must be specified as a multiple of 2nth power (n>=1). Thus, a size larger than the application buffer has to be informed.
Since the transmitting side refrains from data transmission when the receive window size has dropped below Maximum Segment Size (MSS) according to Silly Window Syndrome avoidance algorithm of TCP, it is necessary to inform a window size that is larger at least by MSS.
When a larger window size is informed, the other party may transmit data larger than the application buffer size. If data overflowing the application buffer is not buffered, it will be necessary to have the other party retransmit the data when the next application buffer is specified. On the transmitting side of TCP, retransmission reduces a congestion window size and significantly lowers throughput. Thus, to prevent such retransmission, the overflowing data has to be somehow buffered.
As outlined above, the technique of U.S. Patent Publication No. 2004-0078462 gives rise to at least one of the problems (1) to (3). Data buffering is desired for avoiding these problems, but U.S. Patent Publication No. 2004-0078462 does not disclose a method therefor.
That is to say, when the conventional software-based scheme described above first is applied, buffering is performed and thus the problems (1) to (3) do not arise. However, overhead associated with copying occurs all the time. When the technique of U.S. Patent Publication No. 2004-0078462 is in turn used to avoid such overhead associated with copying, the problems (1) to (3) will be encountered.